Adding 'problems' module #269
Conversation
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…cheduling will fail
for more information, see https://pre-commit.ci
erikvansebille
left a comment
erikvansebille
left a comment
There was a problem hiding this comment.
Nice PR! I quickly went through the code, but mostly focussed on the problem descriptions and have a few suggestions on these
|
|
||
| message: str = ( | ||
| "A pod of dolphins is observed swimming directly beneath the planned deployment area. " | ||
| "To avoid risk to wildlife and comply with environmental protocols, all in-water operations " |
There was a problem hiding this comment.
But what if there are no "in-water" operations at this station. Is it not safer to say "all operations"?
| message: str = ( | ||
| "A miscommunication with the ship's captain results in the sudden initiation of a mandatory safety drill. " | ||
| "The emergency vessel must be lowered and tested while the ship remains stationary, pausing all scientific " | ||
| "operations for the duration of the exercise. The drill introduces a delay of approximately 2 hours." |
There was a problem hiding this comment.
Here, and on all later problems, I'm a bit confused about the word "approximately". In the schedule, it will be exactly 5 hours. So better to remove that word, as it could only confuse students (i.e. they may decide to build 10 hour contingency)?
| message: str = ( | ||
| "The drifter scheduled for deployment fails to establish a satellite connection during " | ||
| "pre-launch checks. To improve signal acquisition, the float must be moved to a higher location on deck " | ||
| "with fewer obstructions. The team waits for the satellite fix to come through, resulting in a delay " |
There was a problem hiding this comment.
"fix" is perhaps a confusing word here?
| message: str = ( | ||
| "The Argo float scheduled for deployment fails to establish a satellite connection during " | ||
| "pre-launch checks. To improve signal acquisition, the float must be moved to a higher location on deck " | ||
| "with fewer obstructions. The team waits for the satellite fix to come through, resulting in a delay " |
There was a problem hiding this comment.
Also here, replace fix with e.g. "waits for the satellite connection to be established"
There was a problem hiding this comment.
Great set of problems! Would be fun to collect a few more at e.g. Ocean Sciences Meeting?
Summary
This PR adds a 'problems' module to VirtualShip, whereby as expeditions are run users are faced with authentic problems which may happen on a real-life research vessel. These can be "general" problems (e.g. delayed food/fuel deliveries, unplanned safety drills), or "instrument" problems (e.g. CTD winch breaks down).
Features & implementation
All problems are associated with a delay duration. There are checks of whether there is already enough contingency time built into the schedule to still reach the next waypoint in time. If there is then the simulation is allowed to continue. However, if the next waypoint would be missed, users are prompted to account for the delay in their schedules and the expedition cannot proceed until the scheduling is resolved.
The problems module interacts with
Checkpointobjects to test that the scheduling issues have been resolved. A unique record of the problems is also cached to keep track of and determine whether they've been resolved etc. It may be that dealing with a problem at one waypoint causes more scheduling issues way down the chain of waypoints. This is by design (as similar headaches would be experienced in real life!) and the schedule/checkpoint verification methods should capture this and prompt further changes.The selection of problems and their execution in the main
virtualship runworkflow is handled by a newProblemSimulatorclass. Specific problem scenarios are housed inscenarios.pyas problem classes, which are themselves sub-classes ofGeneralProblemandInstrumentProblembase classes (to establish a structure for building complexity in further PRs).When propagated through
virtualship run, a selection of all the problems for the expedition is first created but the individual problems are only raised at the right time. For example, a pre-departure problem will occur before any instrument simulations and a CTD related problem only when the CTD instrument is being simulated.A new 'prob-level' argument is now added to the
virtualship runCLI command. There are three options to choose from:N.B. I have set the default to
prob_level = 1for now, as this is best for upcoming in-class VirtualShip use.Additional notes
I have set up the logic so that if waypoints are added/removed from the expedition, if a waypoint location changes or the instruments employed changes, this will prompt a new set of problems for the expedition. I see this as the expedition having materially changed and it being a 'new' expedition. This also prevents just re-running the same expedition until you get a 'nicer' set of problems (without manually removing the problems cache!).
Closes #120